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redundant, secure, encrypted and viral scrubbed at the network level. My focus is largely 
concentrated on the survival and security of corporate or governmental communications. 
Gartner focuses on satellite communications while I do not. Underwood focuses on the 
flexible software architecture for a call processing system while I intend to lease IP 
VPNS on AT&TS meshed optical network. 

As I went through the list, I saw the Schnarel disclosure on Graphical User 
Interfaces. I will do that on our Web site for application configuration. However, that is 
not something I am interested in implementing on a communications device level. 
Burgess discloses a method and system for performance monitoring in computer 
networks. This is not something I discuss in this patent application. Blakely discloses 
configurable password servers for use in a shared resource environment. While I do use 
passwords, DID, ANI and pin numbers, and anticipate the use of voice printing and caller 
ID etc., I lay no claim to patenting any of those ideas. Lucas and Elliott don't really seem 
to apply to this patent application. 

Amended Claims 
Claim 1 is currently amended and now reads: 

1 . (Currently Amended) A method of configuring a communications system 
currently utilizing CALL PULL-BACK technology as disclosed in the issued U.S. 
Patent, Serial No. 6,088,437, dated July 11, 2000. The Objects are first disclosed in the 
ABSTRACT OF THE DISCLOSURE page 85, lines 16-19, of this patent application. 
This patent application contains a copy of the issued U.S. Patent CALL PROCESSING, 
METHOD AND COMPUTER PROGRAM PRODUCT. A copy of said patent is 
included in the appendix of this patent application at page 85, which is also a copy of 
page 33 of U.S. Patent CALL PROCESSING, METHOD AND COMPUTER 
PROGRAM PRODUCT wherein it is stated that the signaling attributes and customer- 
specific information are controlled by Objects, which are well thought out 
preprogrammed and proven software constructs that simplify programming and ensure 
reliable operations. The Objects allow for the creation of client specific structures such 
as that shown in figure 10 located on page 36 and provide call processing, plug in 
applications modules, multimedia, messaging, video and voice and video conferencing. 
Over time, hardware and software upgrades require rewriting of the Objects. What 
doesn't change is the basic functionality of the OBJECTS as defined in the Object/Class 
of Service documentation incorporated in the body of this patent application: The 
OBJ/COS numbers 0 through 511 each contain a sentence reminding an experienced user 
what that object is for, whether or not that Object is associated with a specific area code, 
and a more detailed description of the functionality of that Object to be used by those less 
skilled in configuring a client's application or as a specification used in the rewriting of 
that Object. Once the functionality of each Object is known, it is a simple matter to 
rewrite each Object as needed. This method is comprised of the following steps: 

Placing a user's mailbox in the appropriate Object. A hypothetical example 
would be mailbox 1000 has a phone number associated with it and it is placed in Object 
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5 1 . It would be entered in the user's table as 1 000,xxxxxxx,5 1 . Xxxxxxx would equal 
the 7-digit phone number to be dialed. A caller entering that mailbox number would 
cause the Call Processor to automatically dial the appropriate access code - in this case, 9 
then 1,305 and the 7-digit phone number associated with the mailbox number to the 
PSTN. Call Pull Back is engaged and if no one answered a greeting would be played and 
the caller would be offered an option to leave a message. While listening to the greeting 
the caller could enter another extension number or select a menu choice. The other 
Objects, while different, are just as simple as Object 51. User definable parameters are 
such things as security codes, greetings, cell or pager numbers, message waiting times, 
etc. [Emphasis added.] 

If the more detailed explanation for Claim 1 is acceptable then it seems that Claim 
2 should be accepted as well. Claim 2 is currently amended and now reads: 

2. (Currently Amended) The method of Claim 1, wherein the predetermined 
functions are associated with said CALL PULL-BACK mechanism. 

In the detailed action, it is stated that Claim 11, which is a system of Claim 10, 
was rejected under 35 U.S.C. 1 12. I believe that in light of the amended Claim 1, both 
Claims 1 1 and 10 are somewhat redundant with Claim 1 . In addition, I find Claims 12 
and 13, both of which are systems of Claim 10, are redundant with that stated in the 
amended Claim 1 . In order to simplify matters, I hereby withdraw Claims 10, 1 1, 12 and 
13. Claims 22 and 23 are also somewhat redundant with that stated in the amended 
Claim 1, so in the spirit of simplifying matters I am withdrawing them as well. 

In reviewing the revised patent application submitted herewith, please note that 
the Call Pull-Back the technology is disclosed in the issued U.S. patent, Serial No. 
6,088,437, dated July 1 1 , 2000. This is a previous patent of mine and a copy of this 
patent is included in the appendix. 

Differentiation of this Patent Application and Other Patents 

In response to your denial of this patent application under 35 U.S.C. 103 (a), I 
submit that this patent application is different from and distinguished from other patents. 

As per Claim 1 (Page 3). In Barnhouse, a review of the BACKGROUND OF 
THE INVENTION column 1, lines 30 through 67, and column 2, lines 1 through 10, 
reveals the difficulties Barnhouse sought to overcome concerning proprietary software 
and firmware designed by the switch manufacturer and the difficulties involved in 
implementing new services or modifications of existing services. The fact that each 
network contains different switch models from different manufactures requires careful 
development, testing and deployment of new software. The time frames involved are 
prohibitive and the problem of differentiating services by the competitors is a difficult 
one to overcome. 
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In contrast to Barnhouse, my invention has no need to overcome those problems. 
From the beginning, I centralized the deployment of applications and services, hosting 
them in my NOCCS. While I could provide services to all 50 states from a single 
location, I decided on a minimum of two locations separated by a large geographic 
distance so that I could mirror functionality and messaging in case of a natural or man 
made disaster. Later that was expanded to four locations for the same reason. In my 
case, unlike Barnhouse, all the hardware was off the shelf, (e.g., SUN gear) and at the 
same hardware, firmware and software release. I didn't have the legacy problems faced 
by network owners and was able to concentrate on network protection and developing 
applications for end users. 

The use of the generic term Object isn't the issue. The issue is one of the 
functionality of the Object. I created specific, defined software Objects that allow non- 
technical personnel who understand the business needs of a client to rapidly and reliably 
create, manipulate or destroy a given application. These specific defined software 
Objects also act as a common operating control in that they issue commands to other 
servers invoking related applications. These applications provide structure allowing one 
to create a virtual environment, which may partially or totally mirror the applications, call 
processing and messaging of a client having a physical corporate location or being 
scattered across large geographic distances working from various locations such as a 
home or hotel. All that is necessary is access from any communications device to the 
network. 

These specific, defined software Objects enable one to cost effectively create a 
custom application for every client, thereby giving a huge advantage to the application 
creator over a competitor. After carefully reading DEC CIT, it is my belief that it not 
only does not conflict with this patent application, but that I am doing totally different 
things. 

As per Claim 2 (Page 5). I believe I have demonstrated that there is no 
equivalency between Claim 2 and the call processor and the communications interface 
disclosed in Barnhouse. Our Objects provide structure and plug in applications enabling 
a client to continue operation despite man made or natural disasters. 

As per Claim 3 (Page 5). For the reasons stated above, I see no equivalency 
between the Objects disclosed in Barnhouse and the Objects disclose in this patent 
application. 

As per Claim 4 (Page 5). There is no equivalency between the Objects disclosed 
in Barnhouse and the Objects disclosed in this patent application, so I'm not sure if this 
detailed action as per Claim 4 would apply. If you feel it does, I will withdraw Claim 4. 

As per Claim 5 (Page 5). Barnhouse suggests distribution of functions to network 
resources or customer systems with interface to activate those functions. That is not what 
I am claiming. What I am claiming is simply an office in a box. A new customer who 
has no connection to our network purchases a CD with a license in a box. He puts the 
CD in his computer and is taken to our Web site. The CD is queried and the user is 
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allowed to create a simplified Virtual Office application. Larger applications are much 
more complex and require attention to business detail which may not be obvious to the 
average user. If you feel these virtual office applications conflict with Barnhouse or CIT- 
DEC, I will withdraw Claim 5. 

As per Claims 6, 7, 8 and 9 (Page 6). These Claims are all associated with the 
virtual office in a box concept. This was never intended to be an application. It is simply 
purchased and installed on a home computer. This was intended as a marketing method, 
development and management tool allowing a potential client the ability to construct a 
simplified virtual office application that resided on the servers in the various NOCCS of 
our network. I thought it was an interesting concept. To my knowledge, no one has 
come up with a customizable virtual office that (1) operates on a hardened, secure, clean, 
hacker resistant network; (2) knew where the user was likely to be and directed all traffic 
to the last known location of that user first; (3) networked the users of a given client 
together by processing calls, offering access to other applications and providing mixed 
media messaging from any device to any device, thereby allowing the outside world to 
interface with clients just like they were in a traditional corporate or governmental office 
at a flat monthly rate without metered charges. If you feel this was obvious I will 
withdraw Claims 6,7,8 and 9. 

As per Claims 10 (Page 6), 1 1, 12 (Page 7) and 13 (Page 8). As previously stated 
in this document, I believe these are somewhat redundant with that stated in the amended 
Claim 1, so in the spirit of simplifying matters I am withdrawing them as well. 

Claim 14. As Claim 10 is withdrawn and Claim 14 is a system of Claim 10, 1 will 
withdraw Claim 14. 

Claim 15. As Claim 14 is withdrawn and Claim 15 is also a system of Claim 10, 1 
will withdraw Claim 15. 

As per Claim 16 (Page 8). Claim 16 is currently amended and now reads: 

16. (Currently Amended) A computer program product, comprising: 

a computer storage medium and a computer program code mechanism 
embedded in the computer storage medium for causing a processor to implement a call 
processing system, utilizing Call Pull-Back. 

A computer program code mechanism comprising: 

a first computer code device configured to create a library of 
preprogrammed software objects capable of performing predetermined functions such as 
the ability to create, manipulate and destroy a structured virtual environment application 
with plug in application modules, call processing in both a switched circuit and packet 
environment, multi-media messaging, video and video and voice conferencing; 
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a second computer code device configured to store the library of 
preprogrammed software objects in a digital repository; 

a third computer code device configured to select a subset of 
preprogrammed software objects from the digital repository based on a preselected 
portion of the predetermined functions; 

a fourth computer code device configured to customize the selected 
preprogrammed software objects based on user defined parameters; and 

a fifth computer code device configured to process calls based on the 
selected programmed software objects as customized with the user defined parameters. 

As per Claim 17 (Page 9). If the more detailed explanation for Claim 1 is 
acceptable then Claim 2 and Claim 17 should then be acceptable as well. 

As per Claim 18. Yes, Barnhouse discloses a database but there is no equivalency 
between that disclosed in Barnhouse and this patent application. The use of a database is 
not the issue. The issue is what that database is used for. More importantly, Barnhouse 
doesn't address the ability to create structure and it does not appear that his intent was to 
create a hardened, redundant, mirrored, encrypted network that scrubbed traffic at the 
network level to ensure freedom from infection by viruses, worms and so on. 

As per Claim 19 (Page 9). Again there is no equivalency between that disclosed 
in Barnhouse and this application. Normally one would note the Objects used in a 
client's application, their relation to one another and the variables they are populated 
with, and then create a drawing representing that given client's configuration. What I 
have done is to create a master drawing stored on a computer that allows the person 
documenting a given client's configuration to delete from a copy of the master drawing 
by highlighting the unneeded parts of the drawing and pressing the delete key. What's 
left is inputting the variables and the client's contact information. 

As per Claim 20 (Page 9). If the more detailed explanation for Claim 1 is 
acceptable, then Claim 2, Claim 17 and Claim 20 should then be acceptable as well. 

As per Claim 21 (Page 9). The detailed action references Barnhouse^ column 14 
lines 29 through 59. Our network and the services it provides are billed to a client at a 
flat rate. Consequently, there are no metered charges and, therefore, there is no need for 
a session manager to gather billing information. Further, the entire digital portion of the 
network utilizes burstable bandwidth so no service control class is needed. In reviewing 
Barnhouse column 16 lines 8 through 27, please note the use of a connection manager 
class. Our network utilizes no connection manager class. We simply use off the shelf 
equipment for the simple reason that no one funds a network like this unless it operates 
on off the shelf equipment and utilizes today's proven technology. These days no one 
funds futures — particularly on this scale. With this in mind, we devoted our resources to 
designing a network and developing specific, defined software Objects that provided 
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applications and services that a client needs and that we stood a chance of marketing. In 
reviewing CIT-DEC and the definition of parameters in creating call processing 
functionality, it strikes me that it's similar to the use of a database as set forth above in 
my comments regarding Claim 18. The use of parameters in creating call processing 
functionality is not the issue. The issue is what the parameters are used for. While there 
is call processing involved, my Claim 21 states that said user defined parameters are 
communication system attributes and as such are a computer product of Claim 16. 

As per Claim 22 (Page 10). If the amended Claim 1 above is accepted, then 
Claim 22 should be accepted as well. 

As per Claim 23 (Page 10). If the amended Claim 1 above is accepted, then 
Claim 2 and Claim 23 should be accepted as well. 

As per Claim 26 (Page 1 0). I withdraw this Claim. In the three years that have 
passed since the submission of this patent application and its examination I no longer 
need to lock up bandwidth for a virtual point to point connection. I now utilize packet 
prioritization and burstable bandwidth. 

Claim 27. I withdraw this Claim as well for the reasons stated for the withdrawal 
of Claim 26. 

As per Claim 28 (Page 1 0). Claim 28 is now currently amended and reads: 

28. (Currently Amended) The system of Claim 22, further comprising: 

means for controlling numbering and forwarding from the call or applications 
processor located within the NOCCS servicing the client. 

As per Claim 29 (Page 1 0). I concur and hereby withdraw Claim 29. 

As per Claim 30 (Page 1 0). The spoken verbiage I am referring to in this Claim is 
not that of that of the developer's comments or his personal identification. It is the 
greetings spoken to the caller and the contact information of the client. 

As per Claim 31 (Page 11). As there is no equivalency between the Objects 
disclosed in Barnhouse and those disclosed in this patent application I fail to see the 
rejection. 

As per Claim 14 (Page 1 1). Claim 14 was withdrawn earlier in this document. 

As per Claim 15 (Page 11). Claim 15 was withdrawn earlier in this document. 

As per Claim 24 (Page 12). Claim 24 addresses disaster resistant 
communications. As you know, we employ a number of means in addressing this issue. 
Our intent is to provide a communications network and applications that are capable of 



overcoming attempted terrorism, a limited nuclear weapons exchange or allowing those 
fleeing a radiological or bio-weapons strike to maintain critical communications and even 
continue functioning though their corporate headquarters or governmental offices may no 
longer exist or have been rendered inoperable. Some of these means are common sense, 
such as security. Some may be employed by others by building a hardened 
communications network such as layering it on top of a self healing optical network or 
employing redundancy. However, that isn't all we are doing here. Some of this would 
only apply to someone attempting to do what I am doing. Let me address the latter 
category. 

As you are aware, I build custom applications that provide structure by either 
duplicating part or all of a client's communications and messaging. These applications 
provide disaster protection by answering calls and automatically redirecting traffic to the 
last known device the called party used to log in from. In addition, I utilize more 
common forms of tracking down a client such as allowing clients the ability to redirect 
traffic to a device of their choosing. 

When I create an application for a client, it is hosted in one of the NOCCS and I 
further ensure the survival of a client's application, i.e., the client's communications, 
messaging and application structure, by mirroring that application in another NOCC 
located in another part of the country. These applications and messaging are hot standby 
copies of one another. If one fails, the other takes over until the damaged application can 
be restored. The ability of a client to access the network from any communications 
device is a further improvement. 

As per Claim 25 (Page 12). (Withdrawn) I have discovered another means of 
accomplishing this so that the user's node access as a local call is never exceeded. This 
method is a trade secret and will not be revealed in this application. 



As per Claim 27 (Page 13). (Withdrawn) 




John Kenneth Amick 



